DRUVEXAA · NETWORKING
Type any website. Watch the query leave your machine, climb the DNS hierarchy from the root down to the authoritative server, and come back as an IP address — with the real packet contents shown at every hop.
Pick where to start — you can switch at any time.
name → address, one hop at a time
Your phone will do exactly what a browser does with google.com — take a name it was given and find the number behind it.
A distributed, hierarchical, heavily cached database
DNS is a distributed database spread over millions of servers, holding one global namespace. Applications
use it to turn a name such as www.example.com into the data needed to
reach a host — usually an IPv4 address (an A record) or an IPv6 address (an AAAA record), but
also mail routing, service locations, text policies and cryptographic keys.
The "phonebook" comparison is convenient but incomplete: a phonebook is one book that someone owns. DNS has no central copy. Every zone is published by whoever runs it, and the tree of delegations is what stitches those independent zones into one namespace.
Read a name right to left. Every fully qualified name ends with an invisible dot — the root:
www.example.com. │ │ │ └── root zone (.) │ │ └────── top-level domain (com) │ └────────────── second level, the registrable domain (example.com) └────────────────── host / subdomain label (www)
Each label is at most 63 bytes, the whole name at most 255 bytes. Labels are compared case-insensitively, though resolvers may randomise case on the wire (0x20 encoding) to make spoofing harder.
A zone is the slice of the tree one administrator actually publishes. The root zone does not contain
example.com; it contains a delegation: NS records saying "ask these servers about
com". The com zone in turn delegates
example.com downwards.
A referral carries NS records in the authority section. If the name servers live inside the
zone being delegated (ns1.example.com serving example.com),
the parent must also ship their addresses in the additional section. Those addresses are
glue records — without them the resolver would have to look up a name that only that same server can answer.
Your machine sends one recursive query with the RD (Recursion Desired) bit set: "give me the final answer, I'll wait." The resolver then sends a series of iterative queries with RD=0. Root, TLD and authoritative servers never chase referrals for you — they answer with what they know and point one level down.
So the client makes 1 query; the resolver may make 3, 4 or more. The chain in this simulation is the classic cold path: root → TLD → authoritative.
There are 13 root server identities, lettered a through
m.root-servers.net — a limit that comes from fitting the whole list plus glue into a
512-byte UDP response, not from there being 13 machines. Each identity is announced by anycast from many sites, so
those 13 addresses are served by well over a thousand physical instances worldwide, run by twelve independent
organisations. A resolver learns the list from a small root hints file it ships with, then keeps it fresh
by priming.
Every record carries a TTL in seconds. Whoever receives it may keep it until the TTL expires, and must count the TTL down as it serves the cached copy. That is why the cold path in this simulation happens rarely and the warm path — a cache hit in your browser, your OS or your resolver — is the normal case.
Failures are cached too. An NXDOMAIN (no such name) is stored using the SOA record's minimum field, which is why a freshly registered domain or a DNS typo can appear "broken" for minutes after it has been fixed. Shortening TTLs a day before a planned migration is standard practice for the same reason.
A CNAME at the queried name replaces it: the resolver restarts the lookup at the target, which is why CDN-hosted sites often show a CNAME chain before the final A record.
Plain DNS answers are unauthenticated, which made cache poisoning practical. DNSSEC signs each RRset with an RRSIG; a DS record in the parent zone commits to the child's key, forming a chain from the root's trust anchor down to the answer. A validating resolver checks that chain and returns SERVFAIL rather than a forged answer. It provides authenticity and integrity — not confidentiality; that is what DoT/DoH are for.
Authoritative servers may tailor replies by the resolver's location or by EDNS Client Subnet, and may return several addresses in rotation. CDNs use this to send you to a nearby edge node. Two people resolving the same name at the same second can legitimately get different IPs — DNS is a lookup, not a guarantee of a single truth.
dig +trace www.example.com # watch the same walk down the tree dig www.example.com A +noall +answer dig example.com NS nslookup -type=MX example.com resolvectl statistics # Linux stub resolver cache ipconfig /displaydns # Windows OS cache
Druvexaa · Visualise the Invisible